Subject: Multiple DLSw frames per TCP segment

From: [email-masked] (Ravi Ramaswamy)
Date: Wed, 24 Jan 1996 08:13:00 +0000

Hi!

Apparently one of the major benefits of DLSw is the fact that multiple 
packets can "packed" into a single TCP segment over the WAN, reducing 
overhead.  I have not been able to find any references to this aspect of 
DLSw in the RFC (1795).  Can you point to the right section?

Thanks

Ravi Ramaswamy
AT&T Bell Labs
[email-masked]

---

From: canary!alan (Alan Bartky)
Date: Wed, 24 Jan 96 08:53:21 PST

This message is in response to Ravi Ramaswamy of AT&T.

> DLSw in the RFC (1795).  Can you point to the right section?

There is no actual text reference to the fact the packets (DLSw
messages) can be packed into a single TCP segment.  In addition a DLSw
message may also be split between two TCP segments.  These consequences
all occur due to the fact that TCP is a CHARACTER BASED streams protocol
(not really a message based) the text that talks about the use
of TCP and the port numbers is in section 3 as follows:

   Before Data Link Switching can occur between two routers, they must
   establish two TCP connections between them.  Each Data Link Switch
   will maintain a list of DLSw capable routers and their status
   (active/inactive).  After the TCP connection is established, SSP
   messages are exchanged to establish the capabilities of the two Data
   Link Switches.  Once the exchange is complete,  the DLSw will employ
   SSP control messages to establish end-to-end circuits over the
   transport connection.  Within the transport connection, DLSw SSP
   messages are exchanged.  The message formats and types for these SSP
   messages are documented in the following sections.

   The default parameters associated with the TCP connections between
   Data Link Switches are as follows:

   Socket Family     AF_INET        (Internet protocols)
   Socket Type       SOCK_STREAM    (stream socket)
   Read Port Number  2065
   Write Port Number 2067

The key text above is "Within the transport connection, DLSw SSP messages
are exchanged."

For TCP, the messages are parsed from the TCP character stream via the standard
message format which always starts with the same header format 
(as defined in section 3.1) which begins with:

   +-----------------------------+-----------------------------+
   | (00) Version Number         | (01) Header Length          |
   +-----------------------------+-----------------------------+
   | (02) Message Length                                       |
   +-----------------------------+-----------------------------+

That section also states in the text:

   ... The INFOFRAME, KEEPALIVE and IFCM
   message headers are 16 bytes long, and the control message header is
   72 bytes long.  The fields in the first sixteen bytes of all message
   headers are the same.

Once a TCP session is established, the length fields and standard
header formats are used to build DLSw messages out of the character
stream.

An implementation could in theory always align one or messages so that
they always start right after the TCP header on transmit, but when receiving
frames, it must assume it is dealing with a streams protocol, and therefore
parse the characters into messages and not assume anything about where
the messages are within the actual TCP segments.

Regards,

Alan

P.S.  Hope you all out there in SNA land are doing well.
I've moved on to virtual LANs and switching.

**********************************************************
Alan K. Bartky                       Email:[email-masked]
Principal Software Engineer
XYLAN Corporation                    Voice:(714) 597-8042
15707 ROCKFIELD BLVD STE 155F        FAX:  (714) 597-8342
IRVINE CA 92718-2830
**********************************************************